In many client-server applications, such as IP Television (IPTV), the number of clients requesting a particular service can be quite large. Because any computer has finite processing capability, a server may only provide service to a limited number of clients before the quality of service degrades to unacceptable levels. The most obvious solution, simply providing faster server components, can become prohibitively expensive and technologically impossible as the number of active clients increases. Accordingly, many client-server applications provide multiple redundant servers in order to accommodate all client requests. Various forms of load balancing are then employed to ensure that no single server becomes too bogged down in serving client requests.
In a rudimentary form of load balancing, multiple servers may be provided and the client may simply choose one server to process a request. This can be seen in applications such as file mirroring, where a list of multiple computers serving the requested file are presented to a user, who then simply picks a server to download from. Other information may be provided, such as the current status or geographic location of the server, but the onus is on the user to process this information and make an informed server selection. If the chosen server does not provide the quality of service expected by the client, a different server may be selected.
In another form of server load balancing, a client may send multiple requests to multiple servers and simply accept the first response that arrives, discarding any later arriving responses. Again, this requires more work on the part of the client, as the request must be duplicated and transmitted to multiple addresses. A multicast protocol may be used to send a single request to multiple destinations, but again, this method places the burden on the client, the servers and the network. The server(s) would need to know each client it serves and join a multicast group hosted by the client. This is not practical.
In a more advanced form of load balancing, a central server may arbitrate from which server a client will receive service. According to this method, a client may send its request to a central server which will then determine an appropriate working server to provide service to the client. The central server may then either respond to the client with the address of the assigned working server or hand the initial request directly to the working server. Thus, this method can require the client to perform unnecessary session establishment and exposes the client to at least a portion of the inner workings of the server system. This method may also carry the added disadvantage of leaving server system more vulnerable to attacks such as, for example, a denial of service attack.
Additionally, a central server would have the same limits as any other computing system and may likewise receive too many establishment requests to process efficiently. Thus, in particularly high client volume applications, multiple central servers may be required and the problem becomes recursive. Another form of load balancing must then be implemented in order to ensure that no central server receives more requests than it can efficiently process.
Accordingly, there exists a need for a method of balancing server load between multiple servers without needlessly complicating the methods performed by client devices in requesting a service. Additionally, a need exists for a method to balance server load in a manner that is virtually invisible to client devices.
Another possible point of failure for any network system is in the links connecting network nodes. IEEE 802.1AX, which is incorporated herein by reference, provides for link aggregation groups (LAGS) that combat this possibility. A LAG is made up of multiple links between the same two nodes. When sending a packet over a LAG, a sending node simply selects one of the links that make up the LAG and transmits the packet over one of the selected link. A LAG is given an identifier such as the MAC address of one of its constituent links. In this manner, a packet may be transmitted over one of multiple links toward its destination in a manner that is virtually invisible to all devices other than the two devices at either end of the LAG. If one link fails, packets may still be transmitted over the remaining links in the LAG.
While effective in combating link failure and increasing transfer speeds, LAGs are not useful for many other problems. The operation of a LAG is very simple and not highly customizable. Thus, LAGs are not particularly helpful when devising new and creative methods of fixing network problems and increasing performance. Accordingly, there exists an additional need for a LAG implementation allowing a higher degree of functionality and customization.
The foregoing objects and advantages of the invention are illustrative of those that can be achieved by the various exemplary embodiments and are not intended to be exhaustive or limiting of the possible advantages that can be realized. Thus, these and other objects and advantages of the various exemplary embodiments will be apparent from the description herein or can be learned from practicing the various exemplary embodiments, both as embodied herein or as modified in view of any variation that may be apparent to those skilled in the art. Accordingly, the present invention resides in the novel methods, arrangements, combinations, and improvements herein shown and described in various exemplary embodiments.